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Sovelluskohtaisten palvelunlaadun optimointlen ohjaus 

Nyt esilla oleva keksinto kohdistuu oheisen patenttivaatimuksen 1 joh- 
danto-osan mukaiseen menetelmaan, jonka avulla voidaan ohjata 
5 sovelluskohtaisia palvelunlaadun optlmointeja kayttaen yleisia palvelu- 
tason signalointiprotokollia. Keksinto kohdistuu lisaksi oheisen patentti- 
vaatimuksen 10 johdanto-osan mukaiseen palvelutason signalointipro- 
tokollaan. 

10 Tiedonsiirtoverkoissa, kuten TCP/I P-verkoissa (Transmission Control 
Protocol/Internet Protocol) on tarjolla erilaisia palvelunlaadun (QoS, 
Quality of Service) signalolntiprotokollia, kuten RSVP (Resource 
Reservation Protocol) ja DiffServ (Differentiated Services). Naita 
protokollia kaytetaan viestittamaan tiedonsiirtoverkon solmuille miten 

15 tiettyjeri pakettien kasittelyssa tulisi toimia. Tama tarkoittaa esim. sita, 
etta nama paketit tulisi rertittaa eri relttia pitkin, etta reitittimien pitaisi 
lajitella nama paketit niille sopivaan jonoon, tai etta nama paketit tulisi 
valittaa kayttaen erilaista linkkia tai linkkitason palvelua (esim. ATM:n 
tapauksessa eri virtuaaliyhteytta). 

20 

Edella luetellut palvelunlaatuun kohdistuvat operaatiot ovat riippumat- 
tomia sovelluksesta, mutta on olemassa myos eri sovelluksilie ominai- 
sia eli sovelluskohtaisia palvelunlaatuun vaikuttavia operaatioita. 
Esimerkkina voidaan mainita RTP-kohtainen optimointi (Transport 
25 Protocol for Real-Time Applications), eli RTP-otsikon pakkaus. 

Otsikonpakkauksen lisaksi on mahdollista kayttaa useita eri RTP- 
kohtaisia suorituskyvyn optimointikeinoja. Naiden kayttamlsen esteena 
on se, etta tiedonsiirtoverkon solmun on vaikea tunnistaa RTP-tietovirta 
30 (RTP Stream) luotettavasti muusta liikenteesta. Tama johtuu siita, etta 
RTP:ssa ei ole olemassa tiettyja portteja tai luotettavasti tunnistettavia 
yksilollisia otsikkokenttia. Taman takia ei ole kannattavaa kaynnistaa 
RTP-kohtaista optimointia tietylle tietovirralle. Se voi olla jopa mahdo- 
tonta, jos esim. RTP-optimointl muuttaa liikenteen kulkemaa reittia. 

35 

Ongelmana on, etta tiedonsiirtoverkon solmujen ei ole mahdollista 
tunnistaa luotettavasti RTP-paketteja kayttaen yleisia ja suoraviivaisia 
keinoja. Yleensa tietyt sovellukset erotetaan muusta liikenteesta siita, 
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etta ne kayttavat tiettya kuljetusprotokollan porttia (esim. HTTP kayttaa 
TCP-porttia 80), tai niiden ofsikon kentat pystytaan tunnistamaan. 
Vaikka on suositeltu, etta sovellukset kayttavat UDP-porttia 5004 RTP- 
liikenteelle, nlin kaytannossa RTP:n kanssa kaytetaan satunnaisesti 
5 valittuja porttinumero'rta. Tama johtuu siita, etta yhteen sovellukseen 
kuuluu yleensa useita eri tietovirloia, jotka kukin kayttavat eri UDP- 
porttia, ja lisaksi useat sovellukset volvat yhtaaikaa kayttaa RTP:ta 
samassa tietokoneessa. Samoin RTP-otsikko on hyvin yksinkertainen 
ja useimmat siina olevat arvot ovat luonteeltaan satunnaisia. 

10 

Eras tapa RTP-tietovirran tunnistukseen luotettavasti on istuntotason 
protokollan tutkiminen. Istuntotason protokollassa (esim. H.245 tai 
SDP) vaiitetaan istuntoon kuuluvien RTP-yhteyksien kayttamat IP- 
osoitteet ja portit, samoin kuin kaytettavat koodekrt ja pakettien koot. 
15 Ongelmana on, etta tailaisen istuntotason protokollan paketit kulkevat 
tyypillisesti eri reittia kuin RTP-yhteys, ja etta paketit on tyypillisesti 
salattu paasta paahan. 

Tunnetun teknlikan mukaan yleensa voidaan kuitenkin olettaa, etta 
20 RTP-otsikonpakkausta tai RTP-multipleksausta on mahdollista soveltaa 
suoraan RTP-lahteessa tai RTP-vastaanottajaa edeltavassa solmussa. 
Tassa tapauksessa lahde tai vastaanottaja voi kayttaa linkkikerroskoh- 
taista (Link Layer) signalointia aktivoidakseen otsikonpakkauksen 
(Header Compression) tai multipleksauksen toisessa paassa yhteytta. 
25 On mahdollista levittaa tiedonsiirtoverkkoon tieto siita, etta jos vas- 
taanotettavassa tietovirrassa on kaytossa otsikonpakkaus, niin tiedon- 
siirtoverkon solmu voi kayttaa otsikonpakkausta myos samaan tietovir- 
taan sen lahtiessa toista linkkia pitkin. 

30 Jos sovellus el pysty signaloimaan RTP-tietovirtaa tiedonsiirtoverkkoon, 
vaan pystyy vain hallltsemaan linkkia, joka on kytketty suoraan tietoko- 
neeseen, jossa sovellusta ajetaan, voidaan RTP-otsikonpakkausta 
kayttaa vain tiedonsiirtoverkon laidoilla. Tunnetun tekniikan mukaisesti 
RTP-muttipleksointia voidaan kayttaa vain laitteiden valilia, joiden vSlilla 

35 on useita paasta-paahan-yhteyksia. Ei ole siis mahdollista kayttaa RTP- 
multipleksointia esim. kahden reitittimen valilia, joiden valilia kulkee 
useita RTP-tietovirtoja. 
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Keksinndn eraana tarkoltuksena on aikaansaada menetelma, jonka 
avulla voidaan kaynnistaa sovellukselle ominaisia liikenteen 
optimointeja lahettajan ja kohteen valisissa tiedonsiirtoverkon solmuis- 
sa, kuten reitittimlssa. 

5 

Tama tarkoitus voidaan saavuttaa siten, etta sovellus kayttaa 
palvelutason (QoS, Quality of Service) signalointiprotokollla merkitse- 
maan sovelluskohtaisia tietovirtoja. Talloin tiedonsiirtoverkon solmut 
voivat palvelutason signaloinnin perusteella tunnistaa sovelluksen 
10 tietovlrrat, jolloin sovelluskohtainen optimointi, kuten RTP- 
otsikonpakkaus tai -multipleksaus, on mahdollista kaynnistaa, jopa 
ennen kuin sovellus on lahettanyt mitaan varsinaista liikennetta. 

Tasmallisemmin sanottuna keksinnon mukaiselle menetelmalle on 
15 tunnusomaista se, mika on esitetty patenttivaatimuksen 1 tunnus- 
merkkiosassa. Keksinnon mukaiselle palvelutason signalointiprotokollal- 
le on tunnusomaista se, mika on esitetty patenttivaatimuksen 10 
tunnusmerkkiosassa. 

20 Nyt esilla olevalla keksinnolla saavutetaan merkittavia etuja tunnetun 
tekniikan mukaisiin ratkaisuihin verrattuna. Kun tietovirran (esim. RTP) 
luonne voidaan signaloida lahettajan ja kohteen valissa oleville solmuil- 
le (esim. reitittimille), mahdollistetaan useita tietovirtakohtaisia optimoin- 
teja. Tallainen signalointi mahdollistaa sovelluksille myos standardin 

25 rajapinnan (API, Application Programming Interface) naihin optimoin- 
teihin. TallOln sovellusta voidaan kayttaa muuttamattomana eri tyyppi- 
sissa aliverkoissa, kuten PPP, GPRS, WLAN. 

Keksintoa selostetaan seuraavassa tarkemmin viitaten samalla oheisiin 
30 piirustuksiin, joissa 

kuva 1 esittaa periaatteellisena kaaviokuvana tilannetta, jossa 
ensimmainen tietokone H1 siirtaa RTP-tietovirtaa toiselle 
tietokoneelle H2 tiedonsiirtoverkon yii, 

35 

kuva 2 esittaa tiedonsiirtoverkossa kulkevaa RTP-pakettia, 
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kuva 3 esittaa periaatteellisena kaaviokuvana tilannetta, jossa 
RSVP:ta kaytetaan RTP:n kanssa, ja 

kuva 4 eslttaa periaatteellisena kaaviokuvana tilannetta, jossa 
5 DiffServ.ia kaytetaan RTP:n kanssa. Eri palveluluokat on 

merkitty kuvaan merkeilla *, ♦, v ja ♦. 

RTP on yksinkertainen protokolla, joka lisaa hyotykuorman eteen 12 
oktettia pitkan RTP-otsikon 12. Tama otsikko, joka on esitetty kuvassa 

10 2, kasittaS mm. versionumeron 14, hyotykuorman tyypin tunnisteen 15 
(PT), sarjanumeron 16 (Sequency number), aikaleiman 17 (Timestamp) 
ja lahteen tunnisteen 18 (Synchronization Source Identifer). Lahde- tai 
kohdeosoitteita ei ole, joten osoitukseen kayttetaan RTP:n alapuolella 
olevaa kuljetusprotokollaa, kuten UDP (User Datagram Protocol), TCP 

15 (Transmission Control Protocol) tai ATM-AAL5 (Asynchronous Transfer 
Mode Adaptation Layer type 5). 

RTP:n toimintaa tukemaan kaytetaan tavallisestl RTCP- 
ohjausprotokollaa (Real-Time Transport Control Protocol). RTCP:ta 

20 kaytetaan RTP-tietovirtojen synkronointiin, seka viiveen vaihtelun ja 
pakettihukan valvontaan. RTCP-liikenne koostuu tyypH'isesti lahetys- ja 
vastaanottoraporteista. RTP-liikennetta ja siihen liittyvaa RTCP- 
liikennetta kutsutaan nimella RTP/RTCP. Kaikki RTP-sovellukset eivat 
kuitenkaan kayta RTCP:ta, sen kaytto on valinnaista. Lahetettaessa 

25 RTP:ta UDP:n paalla RTP-liikenteen porttinumerot ovat parillisia ja 
RTP:ta tukevan RTCP-liikenteen yhta suurempia ja parittomia. 

Kuvaan 1 viitaten ensimmainen tietokone 1a siirtaa RTP-tietovirtaa 
toiselle tietokoneelle 1b. Itse siirtoprosessi on melko yksinkertainen. 

30 Reaaliaikasovellus saa hydtykuorman 13 koodekilta (ei esitetty kuvas- 
sa), varustaa sen RTP-otsikolla 12, joka kasittaa mm. nykyisen aikalei- 
man 17, jarjestysnumeron 16 ja lahteen tunnisteen 15 (32-bittinen 
satunnaisluku). Sen jalkeen, kun edella mainittu sovellus toimittaa 
paketin TCP/IP:lle, TCP/IP varustaa saadun paketin UDP- ja IP- 

35 otsikoilla ja lahettaa taman toiselle tietokoneelle 1b. Kuvassa 2 on 
esitetty tama lahetettava paketti 3, jossa on IP-otsikko 10, UDP-otsikko 
11, RTP-otsikko 12, hyotykuorma 13 (Media payload) ja mahdollisesti 
tayteoktetteja 14 (Pad). 
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Hydtykuorma 13, jota valitetaan RTP:n yli, voi olla hyvin lyhyt. Tallaisis- 
sa tapauksissa RTP-, UDP- ja IP-otsikot 10, 11 ja 12 edustavat suurta 
osaa koko paketin 3 koosta, esim. 40 tavua IPv4 tapauksessa. 

5 

RTP-otsikonpakkausta voidaan kayttaa esim. silloin, kun kaytetaan 
hitaan nopeuden linkkia. RTP-ots!konpakkaus ei silrra otsikoiden vakio- 
osia, kuten lahteen osoitetta 19 (Source IP address) ja kohteen osoitet- 
ta 20 (Destination IP address) sen jalkeen, kun pakattu sisalto on saatu 
1 0 valmiiksi. Vaihtuvat kentat, kuten RTP-aikaleima 17, jarjestysnumero 1 6 
tai IP?tunniste 21 (Identification) pakataan joko lahettamalla perakkais- 
ten arvojen e rot us tai kayttamalla hyvaksi tietoa, etta tama ero on vakio. 

Jotkut linkkikerroksen toteutukset maaraavat minimikoon paketille, 
15 esim. 64 oktettia Ethernetissa ja 512 oktettia Gigabit Ethernetissa, joten 
otsikonpakkaus ei valttamatta yksistaan riita. Yleensa pakettikytkentai- 
sissa tiedonsiirtoverkoissa kunkin paketin prosessointiin kaytetaan tietty 
vakioaika, jolloin pakettien lukumaaran yahentaminen parantaa tie- 
donsiirtoverkon suorituskykya. Tassa tapauksessa sopiva optimointita- 
20 pa on multipleksata usetta RTP-yhteyksia yhteen verkkokerroksen 
yhteyteen. Kun useita RTP-paketteja voidaan valittaa yhdessa verkko- 
kerroksen paketissa 3, tiedonsiirtoverkon kuorma kevenee ja lisaksi 
otsikoiden osuus koko liikenteesta vahenee. Multipleksatun yhteyden 
paatepisteet neuvottelevat multipleksattujen yhteyksien parametrit 
25 siten, ett§ alkuperaisen kaltaiset RTP-tietovirrat voidaan aikaansaada 
uudelleen multipleksauksen purkamisen jalkeen. 

Tietovirta, joka siirretaan RTP:n yli, tarvitsee yleensa tiedonsiirtoverkol- 
ta erilaista suorituskykya kuin muu liikenne. RTP-tietovirta on huomat- 

30 tavasti herkempi hukkuneille paketeille ja viiveelle kuin tavallinen, esim. 
TCP:ta kayttava liikenne. Riittavan palvelutason saavuttamiseksi olisi 
hyva, etta RTP:ta kayttava sovellus kayttaisi myos tiedonsiirtoverkon 
tarjoamia palvelutasomekanismeja. Naiden palvelutasomekanismien 
kayttaminen vaatii jonkinlaista signalointia, sovelluksen on mm. infor- 

35 moitava tiedonsiirtoverkkoa siita, mille paketeille annetaan etuoikeus. 
Signalointiin voidaan kayttaa esim. RSVP:ta tai DiffServin TOS-oktettia. 
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Palvelutason signaloinnin seurauksena tiedonsiirtoverkon valisolmut 
2a f 2b, 2c ja 2d (kuva 1) voivat kohdella tietovirtaan kuuluvia paketteja 
3 halutulla tavalla. Valisolmut voivat tunnistaa tietovirtaan kuuluvat 
paketit, puskurolda nllta Ja siirtaa niita ottaen huomioon palvelutason 
5 vaatimukset, jotka sovellus on asettanut palvelutason signaloinnin 
avulla. 

Palvelutason signalointi voi myos kaynnistaa RTP-kohtaisen optimoin- 
nin, kuten otslkonpakkauksen tal multipleksauksen. Kaynnfstaminen voi 
10 olla joko eksplislittfsta tal implisiittista. Eksplisiittisessa tapauksessa 
tietty palveluluokka tai tietovirran maarittely koskee vain RTP- 
liikennetta. Implisilttisessa tapauksessa valisolmut 2a, 2b, 2c, 2d voivat 
kayttaa palvelutason signalointia lisatietona paatettaessa sovelletaanko 
optjmointia tiettyyn tietovirtaan vai ei. 

15 

Keksinto ei rajoitu mlhinkaan tiettyyn signalointiprotokollaan, vaan sita 
voidaan hyodyntaa minka tahansa palvelutason signaloinnin kanssa. 
Seuraavassa keksintoa kuvataan kayttamalla esimerkkeina kahta 
yleisinta palvelutason signalointiprotokollaa: RSVP:ta ja DiffServria. 
20 Nama protokollat on valittu esimerkeiksi, koska ne edustavat kahta eri 
tyyppista signalointia. Talla halutaan myos korostaa sita, etta keksintoa 
voidaan soveltaa monien erityyppisten signalointiprotokollien tapauk- 
sessa. 

25 RSVP:ssa palvelun varaus tapahtuu seuraavan selostuksen mukaisesti 
viltaten kuvaan 3. Lahdesolmu 1a lahettaa Paf/?-viestin 4 alavirtaan 
kohti kohdetta 1b, eli RTP-tietovirran 6 suuntaan. Kaikki lahteen ja 
kohteen valissa olevat solmut 2a, 2b, 2c, 2d, jotka pystyvat kasittele- 
maan RSVP:ta, ottavat taman Pafft-viestin 4 vastaan, avaavat tietovir- 

30 ralle polun, lisaavat ornan osoitteensa viestiin ja valittavat viestin 
eteenpain kohti kohdetta 1b. 

Lahde 1a kuvaa tietovirran ominaisuudet Pato-viestissa 3 olevalla 
Tspec-objektilla, joka maarittelee tietovirran normaalin siirtonopeuden 
35 (tavuina sekunnissa) ja purskeisuuden (maksiminopeus tavuina se- 
kunnissa ja puskurin koko tavuina). Viestissa olevassa 
SENDER_TEMPLATE-ob\ekX\ssa annetaan tietovirran lahettajan osoite, 
ja SESS/CW-objektissa virran kohteen osoite. . Lahteen 1a ja kohteen 
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1b vSlissa olevat solmut 2a, 2b, 2c, 2d voivat lisata palvelutason 
resurssien maarittelyja ja kaytettavissS olevat ominaisuudet Path- 
vlestissa olevaan ^Dspeoobjektiin. Vastaanottajalle 1b saapuessaan 
Paf/7-vlestl sisaitaa siis tietovlrran kuvauksen {Tspeo) ja kuvauksen 
5 reltin varrella olevista palvelutason resursseista (ADspec). 

Vastaanotettuaan Pafh-viestin 4 vastaanottava tletokone eli kohdesol- 
mu 1b voi varata palvelutason resurssit Jotta tama onnistuisi, kohde 
lahettaa Resv-viestin 5 takalsln yiavirtaan, lahdetta 1a kohden. Tama 

1 0 HesiAViesti kasittaa kuvauksen siita, minkalaista palvelua vastaanottaja 
haluaa. Haluttu palvelu kuvataan Resv-v\es\\ssa olevassa flowspec- 
objektissa, joka muodostuu Tspec- ja Rspeoobjekteista. Kukin valisol- 
mu 2a, 2b, 2c, 2d varaa taman perusteella halutut resurssit ja 
edelleenlahettaa viestin yiavirtaan (kohti lahettajaa) Patfj-viestissa 4 

15 olleen osoitteen perusteella. Kun varaus on tehty koko reitin varrella, 
lahde 1a voi lahettaa kulttauksen varauksesta ResvConf-v\est\\\a (ei 
esitetty). Normaalisti tfesi/Conf-viesti lahetetaan virran kohteelle 1b, 
jotta kohde tietaisi, etta varaus ollaan suoritettu. Taman jalkeen kun 
paketti 3 (kuva 1) saapuu johonkin tiedonsilrtoverkon solmuun, taman 

20 paketin sisaitaman tiedon tyyppi voidaan tunnistaa, jolloin tahan paket- 
tiin voidaan kohdistaa talle tyypille ominaisia optimolntikelnoja. 

RSVP on oliokeskeinen, milla tarkoitetaan sita, etta kaikkien RSVP- 
viesteja kaslttelevien solmujen 2a, 2b, 2c, 2d ei tarvitse ymmartaa ]a 

25 kasitella kaikkia viesteissa olevia kenttia. Solmut, jotka eivat osaa 
kasitelia joitain kenttia, vain valittavat ne eteenpain. RSVPrn kentat eli 
oliot ovat rakennettu siten, etta niita voidaan helposti laajentaa. On 
mahdollista maaritella uusia palveluja, jotka signaloidaan kayttaen 
RSVP:ta muuttamatta protokollan perusrakennetta tai olemassa olevien 

30 palveluiden (mm. controlled load service, guaranteed service) 
toteutusta niissa solmuissa, jotka eivat tue uusia palveluja. 

RSVP: hen tehtavat laajennukset on esitetty seuraavassa: 


35 


• Lahde 1a ilmaisee ehdottamansa tietovirran olevan RTP/RTCP:ta 
Tspec:issa. Tata tarvitaan esim. silloin, kun liikenteen kulkema polku 
muuttuu tunneloinnin seurauksena multipleksatuilla yhteyksilla. 
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• Lahettajan 1a ja kohteen 1b valissa olevat solmut 2a, 2b, 2c, 2d 
voivat ilmaista millaista RTP/RTCP-kohtaista palvelutason optimoin- 
tia ne pystyvat toteuttamaan ADspsalssa. 

• Kohde 1b ilmaisee tietovlrran olevan RTP/RTCP:ta flowspec\ss2i. 

5 

Helpoin tapa toteuttaa RTP-tuki on lisata uudet sovelluskohtaiset 
palveluparametrit edullisesti olemassa olevaan palveluiden kuvauk- 
seen. Sovelluskohtaiset palveluparametrit voivat sisaltaa lippuja, jotka 
flmaisevat millaista kasittelya kohde 1b tarvitsee, jotta se pystyisi 
10 ottamaan vastaan tietovirtaa onnistuneesti. Esimerkiksi on mahdollista 
ottaa kayttoon IP-otsikonpakkaus, UDP-otsikonpakkaus ja RTP- 
otsikonpakkaus. Sovelluskohtaiset palveluparametrit voivat myos 
sisaltaa tarvittavan tiedon herattaakseen optimoinnin ennen kuin mitaan 
liikennetta on edes otettu vastaan. 

15 

Seuraavassa kasitellaan keksintoa DiffServ:in tapauksessa viitaten 
samalla kuvaan 4. DiffServ:issa ei ole erillisia signalointiviesteja, vaan 
toivotut palveluluokat on ilmoitettu erilaisilla merkeilla DS-kentassa (DS- 
kenttana kaytetaan IPv4:ssa TOS-oktettia 22 kuvassa 2) IP-otsikossa 

20 10. Signalointiviesti 9 kulkee itse paketin 3 mukana. Palveluluokat ovat 
voimassa vain tietyn toimialueen 8a, 8b, 8c sisalla. Rajasolmu 7, joka 
on kahden eri toimialueen 8a, 8b rajalla, lajittelee saapuvat paketit eri 
paJveluluokkifn ja merkkaa ne kutakin palveluluokkaa vastaavalla 
merkilla (code point). Tama lajittelu voidaan suorittaa monella eri 

25 perusteella tassa rajasolmussa. Sovellus voi kayttaa jotain signalointi- 
protokollaa eslm. RSVPrta antaakseen tarvlttavat lajitteluparametrit 
rajasolmulle tai sovellus voi itse kayttaa esim. IPv4:n tapauksessa 
TOS-oktettia 22 (Type of service) merkatakseen RTP-paketit 3. Taman 
avulla rajasolmu pystyy luotettavasti tunnistamaan RTP-paketit ja 

30 merkkaamaan ne sopivalla arvolla DS-kentassa. Kun jokin tiedonsiirto- 
verkon muista solmuista 2a, 2b, 2c saa RTP:ta kayttavan paketin, se 
voi turvallisesti kayttaa talle tyypille ominaisia optimointikeinoja. 

Kuvassa 4 on esitettyna eras eslmerkki DiffServ:ista. Tassa esimerkis- 
35 sa IP-puhelu kasittaa kaksi UDP-tietovirtaa, joista toinen kuljettaa aanta 
kayttaen RTP:ta (merkattu kuvaan RTP:na) ja toinen kuljettaa 
valkotaulusovelluksen tietoja ilman RTP:ta (merkattu kuvaan WB:na). 
Rajasolmu 7 lajittelee RTP-tietovirran RTP-luokkaan ja merkkaa sen 
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RTP-luokan merkilla (v). Se lajittelee valkotaulutledon reaaliaikaluok- 
kaan ja merkkaa sen reaalfaikaluokan merkilla (a). Muut tiedonsiirto- 
verkon solmut 2a, 2b, 2c kayttavat RTP-otsikanpakkausta vain tietovir- 
roille, joka on merkitty RTP-luokan merkilla (v). 

Jos kaytettavissa ei ole omaa palveluluokkaa juuri RTP:lle, mutta 
kaytossa on joku yleinen reaaliaikapalveluluokka, esim. VoIP (Voice 
over IP), tiedonsiirtoverkon solmut 2a, 2b, 2c (kuva 4) voivat kayttaa 
palveluluokkaa lisatietona paattaessaan kasittaako tietovirta RTP- 
liikennetta. Esimerkiksi kuvan 4 tapauksessa, jos aani olisi merkattu 
kuuluvaksi reaaliaikapalveluluokkaan, niin talloln tiedonsiirtoverkon 
solmut 2a, 2b, 2c voivat tunnistaa aanen RTP-tietovirraksi seuraavilla 
perusteilla. TOS-oktetin 22 perusteella paketit kuuluvat reaaliaikapalve- 
luluokkaan, lahde- 23 (Source port number) ja kohdeportit 24 
(Destination port number) ovat yhdenmukaisia, paketin pituus 25 (Total 
length) on oleellisesti vakio, RTP versionumero 14 on 2 (V=2), RTP- 
jarjestysnumero 16 (Sequence number) ja RTP-aikaleima 17 
(Timestamp) kasvaa monotonisesti ja hydtykuorman tyyppi 15 (PT) ja 
lahteen tunniste 18 (Synchronization Source Identifier) pysyvat vakioi- 
na. 

Nyt esilla olevaa keksintoa ei ole rajoitettu ainoastaan edella esitettyihin 
suoritusmuotoihin, vaan sita voidaan muunnella oheisten patenttivaati- 
musten puitteissa. 
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Patenttivaatimukset : 

1. Menetelma sovelluskohtalsen palvelunlaadun optimoimfseksi, jossa 
5 menetelmassa optimoldaan mainitulta sovellukselta tulevien 

tietovirtojen kasittelya lahettajan (1a) ja vastaanottajan (1b) valissa 
olevissa tiedonslirtoverkon solmulssa (2a, 2b, 2c, 2d), jossa tledonsiir- 
toverkossa kaytetaan ainakin ytita palvelutason signalointiprotokollaa, 
tunnettu siita, etta sovellus kayttaa mainittua ainakin yhta palveluta- 
10 son signalointiprotokollaa merk'rtsemaan sovelluskohtaisia tietovirtoja, 
jolloin tiedonsiirtoverkon solmut (2a, 2b, 2c, 2d) tunnistavat palveluta- 
son signaloinnin perusteella mainitun sovelluksen tietovirtaan kuuluvat 
paketit (3) ja niiden tyypin, jolloin naihin paketteihin (3) kohdistetaan 
talle tyypille ominaisia optimointikeinoja. 

15 

2. Patenttivaatimuksen 1 mukainen menetelma, jossa menetelmassa 
tiedonsiirtoverkossa vaJitetaan ainakin yhden tyyppisia paketteja (3), 
tunnettu siita, etta mainittuna signalointiprotokollaha kaytetaan palvelu- 
tason signalointiprotokollaa, joka kasittaa pakettien tyypin kuvauksen. 

20 

3. Patenttivaatimuksen 1 tai 2 mukainen menetelma, jossa menetel- 
massa optimoidaan palvelutasoa, tunnettu siita etta signalointiprotokol- 
lana kaytetaan palvelutason signalointiprotokollaa, joka kasittaa opti- 
moinneissa tarvittavia parametereja. 

25 

4. Patenttivaatimuksen 1 , 2 tai 3 mukainen menetelma, tunnettu siita, 
etta sovelluskohtaista optimointia kaytetaan reaaliaikasovelluksen 
tietovirran optimointiin tiedonsiirtoverkon solmuissa (2a, 2b, 2c, 2d). 

30 5. Patenttivaatimuksen 4 mukainen menetelma, tunnettu siita, etta 
sovelluskohtaista optimointia kaytetaan RTP-tietovirran (6) optimointiin. 

6. Jonkin patenttivaatimuksen 1-5 mukainen menetelma, tunnettu 
siita, etta sovellus muodostaa signalointiprotokollan signalointiviestien 
35 (4, 5) avulla sovelluksen tietovirtaa (6) varten optimoidun polun lahetta- 
jan (1a) ja vastaanottajan (1b) valille, jolloin jokaiselta mainitun polun 
varrella olevalta tiedonsiirtoverkon solmulta (2a, 2b, 2c, 2d) varataan 
sovelluksen tarvitsema optimoitu palvelutaso. 
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7. Patenttivaatimuksen 6 mukalnen menetelma, tunnettu siita, etta 
signalolntiprotokollana kaytetaan RSVP:ta, jolloln Path (4), Resv (5) ja 
ResvConf -viestien avulla varataan sovelluksen tietovirralle (6) optimoi- 

5 tu polku lahettajan (1 a) ja vastaanottajan (1 b) valille. 

8. Jonkin patenttivaatimuksen 1-5 mukalnen menetelma, jossa mene- 
telmassa sovellus lahettaa paketteja (3), tunnettu siita, etta sovellus 
liittaa lahetettavaan pakettiin (3) signalointiviestin (9), jonka perusteella 

10 jokainen saavutettu tiedonsiirtoverkon solmu (2a, 2b, 2c), voi suorittaa 
optimoinnin. 

9. Patenttivaatimuksen 8 mukainen menetelma, tunnettu siita, etta 
signalolntiprotokollana kaytetaan DiffServ:ia, jolloin signalointiviestl (9) 

15 kulkee itse paketin (3) mukana paketin DS-kentassa (22) IP-otsikossa 
(10), jonka avulla kukin saavutettu tiedonsiirtoverkon solmu (2a, 2b, 2c) 
voi suorittaa optimoinnin. 

10. Palvelutason signalointiprotokolla, joka on jarjestetty valittamaan 
20 signalointiviesteja tiedonsiirtoverkon solmullle (2a, 2b, 2c, 2d), ja joka 

palvelutason signalointiprotokolla kasittaa valineet tietyn sovelluksen 
tietovirran merkitsemiseen, valineet mainitun tietovirran tyypin valittami- 
seen j'a valineet optimointiparametrien valittamiseen, tunnettu siita, 
etta palvelutason signalointiprotokolla on jarjestetty merkitsemaan 
25 mainitulle sovellukselle kuuluvat tietovirrat tiedonsiirtoverkon solmuja 
(2a, 2b, 2c, 2d) varten, jolloin nama tiedonsiirtoverkon solmut (2a, 2b, 
2c, 2d) on jarjestetty tunnistamaan nama tietovirrat ja kayttamaan 
naihin tietovirtoihin kullekin tyypille ominaisia optimointikeinoja. 


30 


^ 7 

(57) liiylstelmi 

Keksinto kohdistuu menetelmaan sovelluskohtaisen pal- 
velunlaadun optimoimiseksl, jossa menetelmassa opti- 
moidaan mainitulta sovellukselta tulevien tietovirtojen 
kaslttelya lahettajan (1a) ja vastaanottajan (1b) valissa 
olevissa tiedonsiirtoverkon solmulssa (2a, 2b, 2c, 2d). 
Tassa tiedonsiirtoverkossa kaytetaan palvelutason sig- 
nalointiprotokollaa. Sovellus kayttaa tata palvelutason 
signalointiprotokollaa merkitsemaan sovelluskohtaisla 
tietovirtoja, jolloin tiedonsiirtoverkon sofmut (2a, 2b, 2c, 
2d) tunnistavat palvelutason signaloinnin perusteella 
mainitun sovelluksen tietovirtaan kuuluvat paketit (3) ja 
niiden tyypin, jolloin naihin paketteihin (3) kohdistetaan 
talle tyypille ominaisia optimointikeinoja. 


Fig. 1 
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